Presentation software typically allows objects to be animated in a large number of ways. An object's position, rotation, scale, color, etc. can all be animated, and a single animation may manipulate multiple properties simultaneously. This poses a problem for web-based presentation software, because not all web browsers may be able to render all possible animations. Even if browsers support a particular animation, different browsers may have different mechanisms for supporting it. For example, some browsers support animations using Synchronized Multimedia Integration Language (SMIL), a markup language for describing multimedia presentations, while others support animation via Javascript. Because of these browser inconsistencies, a different implementation of each animation may need to be created for each browser.
In the viewer, some level of animation support is necessary for all browsers. If the browser supports Scalable Vector Graphics (SVG), where images and their behaviors are defined in XML text files, the full range of animations can be available. If not, the animations will be limited to what can be achieved by cross-fading two Portable Network Graphics (PNG) images (e.g. incremental reveal). The animation framework needs to be flexible enough to support at least these two cases.
It is important for text to be animatable in the same way as any shape. That is, text should be move-able, scalable, rotate-able, etc. Also, since animations can iterate ‘by paragraph’ or ‘by word’, these effects should be applicable to any portion of the text. This requirement has some consequences for the SVG rendering.
In the editor, though the rendering is done with SVG, text is rendered using a <canvas> element. This is necessary for rendering text quickly during wysiwyg (“What You See Is What You Get”) editing, but since the canvas is a pixel buffer, it does not scale with the rest of the SVG rendering. To get around this limitation, the editor has logic to re-render every canvas when the document is scaled. The same logic would be necessary in the viewer if canvas text was used.
Furthermore, for parts of text to be separately animatable, each part would need to be rendered to its own canvas. Managing all of these canvases and re-rendering them when they need to be scaled would significantly increase the complexity of the viewer. Fortunately, in the viewer, the wysiwyg editing requirement disappears, and the text can be replaced with SVG paths. The down-side of this approach is that the text paths cannot be generated on the client. That is, producing an SVG rendering with animatable text always requires a request to the server.